場景：上線前那場委員會，主席問了一個我答不出來的問題

先說時間點。這件事發生在系統上線之前——前面幾天寫的都是上線之後：清單被禮貌地關掉、模型換版把尺悄悄換掉、判準補到自己跟自己打架，那些當時都還沒發生。這一篇要往回走一段，回到那場決定要不要上線的委員會，因為那天沒有答出來的兩個問題，決定了後面每一件事的形狀。

簡報翻到最後一頁的時候，一切看起來都很順利。

流程跑得動，抽樣改成全量之後看得見的東西多了一個量級；驗證做過，自己造的那批問題報告它抓得到；報表每個月自動跑。範例報表已放進電子會議資料，臨床科的黃主任在筆電上捲動看了幾筆，整場沒有發言。

主席切回前兩頁電子報表，抬頭問了一個我準備過、但沒有準備好的問題：

「這份報表發到單位去的時候，署名是誰？」

我還在想怎麼回答，資訊室的老周接了下一句。他的語氣比較像在幫我，內容其實更難：

「而且如果它判錯了，是我們系統的問題，還是品管室判準的問題？」

那一刻我很清楚一件事：這個東西技術上早就可以上線了。卡住它的地方，一行程式都不是。

走廊上的第二個問題，比委員會那個更早會殺死它

兩週後，陳護理長在走廊上叫住我。她沒有要抗議什麼，語氣甚至有點客氣：

「聽說你們那個系統快上了。所以以後是不是每一份都會看？」

我說對。

她點點頭，停了兩秒，說：「那我們要注意一點。」

這句話聽起來像配合。我回辦公室之後想了很久，才意識到它是整個專案最大的風險。

這兩個問題看起來不相干，一個講權責，一個講感受，其實是同一個問題的兩面：委員會問的是「誰為這個判斷負責」，陳護理長問的是「誰被這個判斷影響」。

我先講她那一句，因為順序就是這樣：署名的問題會在第一次申復的時候爆炸，被監控的問題會在上線第一週就開始發酵。

稽核從一個事件，變成一個狀態

抽樣的時候，稽核是一個事件：這週五、二十份、看完就結束。全量之後，稽核變成一個狀態：你寫的每一筆病歷都會被讀。

第一線的反應不是「怕被抓」，是**「我不知道它在看什麼」**。抽樣時代稽核表上有哪幾條大家都看過，心裡有底；全量之後，判準變成一個跑在別的地方、沒有人看得見的東西。恐懼的來源不是嚴格，是不可預期。

這件事你們比誰都清楚：公司裝了一套新的自動檢查，你的第一個反應不會是「太好了品質會變好」，會是它會擋我什麼、它到底在看什麼、這些數字會不會進我的考核。一模一樣。

所以有三個回應。三個都是設計，不是宣導——宣導對這件事沒有用，因為被監控的人衡量的不是你的誠意，是你的資料結構。

一、判準必須公開，而且只有一份。

不能有「發給單位的稽核條目」跟「系統實際在判的那份東西」兩個版本。這聽起來理所當然，但人工稽核時代做不到：判準的真實版本一直住在資深稽核員腦子裡，文件管理系統裡的那份是簡化版。

反而是自動化之後，判準第一次必須是同一份——因為機器只讀寫下來的那份。這是這個專案裡最意外的收穫之一：逼出透明度的不是決心，是機器只認得寫下來的東西。

二、能連到個人的欄位，不要產生它。

用途邊界不能靠承諾。個人層級的判定結果不進考核——這不是一條政策，是一個 schema 決定：報表產出的最小單位是單位，不是人。

你們在系統設計上早就懂這件事：

能查到的東西遲早會被查。唯一可靠的保護是不要產生那個欄位。承諾會換人，schema 不會。

一條政策的壽命是一任主管；一個沒有被建出來的欄位，下一任主管想查也查不到。

三、回饋必須是雙向的。

系統對單位講話，單位也要能對系統講話。申復管道要在同一個介面裡，而且申復成立之後要看得到判準被修訂——單位要能看見自己的意見改變了什麼。

只有單向輸出的東西，不管你叫它品質改善還是什麼，在被輸出的那一端就是監控。

這件事會直接殺掉全量的價值

Day 1 講過稽核的原罪：一旦宣告要看，現場就會變好，我們拿到的永遠是準備過的版本。全量本來就是拿來解這個問題的——你沒辦法對每一天都做準備。但如果全量被當成監控，會發生什麼？

你不會得到真實的現場。你會得到一個全年無休、準備過的現場。

那就繞回原點了，而且比原本更貴。

走廊上那句「那我們要注意一點」，翻譯出來就是這件事。而它不能靠事後溝通解決，只能靠上線前決定要不要產生那個欄位。

簽名在品質系統裡到底是什麼

現在回到委員會那一題。

醫院裡幾乎每一個會影響到別人的判斷，最後都要有一個名字：處方、稽核判定、事件調查結論、品管圈結案報告。這很容易被當成行政手續，不是。簽名是責任的物理化——它把一個原本只存在於某個人腦子裡的判斷綁到一個具體的人身上，讓它變成可以被質疑、被申復、被追究的東西。

申復是被判定的一方提出異議、要求重新審視的程序，大致等於你們的 dispute 或 appeal。關鍵在於：申復要有對象。 單位不服的時候，程序找的不是「系統」，是那個名字。

所以簽名的功能不是證明你做過，是指定當這件事出錯的時候，要去問誰。這件事你們早就有：PR 的 approver、change ticket 上的核准人、on-call 排班表上這一週的那個名字。

人工稽核時代這條責任鏈是完整的：看的人、判的人、簽名的人、申復時出來解釋的人，是同一個。但它完整不是因為誰設計得好，是因為那時候沒得選——判斷發生在人腦裡，判斷者和責任人不可能分離。

責任鏈是怎麼斷的

AI 進來之後，這條鏈第一次斷成好幾段。

前四行都填得出來。後兩行，那天在委員會上填不出來。

判斷的產生者和責任的承擔者，第一次分離了。

這件事你們比醫院熟。一個自動送上來的相依套件升級 PR，CI 全綠，你看了兩眼按 merge，三天後線上出事——算誰的？大家心裡的答案都是「按 merge 的那個人」，但大家也都知道這答案不太對：按的人根本沒有能力複查那個 diff。你不是在為那個 diff 背書，你是在為 CI 背書。

於是有一個規律，我認為在任何自動化系統裡都成立：

責任不會因為中間多了一個系統就消失，它只會往下游擠。擠到最後一個有名字的人身上——而那個人通常離判準最遠。

所以「誰簽名」不是行政問題。你把簽名欄放在哪裡，等於決定了這個系統的失效由誰吸收。

四種擺法

我們把可能的擺法攤開來討論過：

最後採用的是 C 加上 D。

C 的代價是吞吐量掉下來。所以全量的意義被重新定義過——不是「全部都由系統判定」，而是「全部都被讀過一遍，人只逐筆認定被標出來的那些」。這個區分改變了 AI 的身分：它的產出不是判定結果，是注意力的分配，而決定注意力往哪裡放，跟決定一件事合不合格，責任重量完全不同。

D 才是關鍵設計。責任被拆成兩層：判準這一層（這份判準是誰訂的、什麼時候經過共識會議、當時的條目文字長什麼樣，責任人是品管室，具體是我），和個案這一層（這一筆為什麼成案、認定當下看到了什麼，責任人是那位認定者）。

分開之後，申復也跟著分成兩種，處理路徑完全不同：「這一筆判錯了」走個案處理，改判、留紀錄，當天結束；「這一條判準本身不合理」走判準修訂，回共識會議，而且會影響所有用同一版本判過的案子。

人工時代這兩種是混在一起的，因為判準沒有版本，只能一件一件吵。吵贏的那一次不會變成下一次的規則，於是同一個爭議每年重來一遍。

而 D 只有在判準是可指認的版本的時候才成立。這裡接上 Day 27 那條版本戳：當時的理由是可重現性，現在回頭看，它還有第二個、可能更重要的功能——版本號是責任的地址。

這套東西你們也早就有：出事的時候 git blame 到那一行，找到 PR，找到 approver，找到當時的 review comment。醫院原本沒有這個，因為判斷發生在人腦裡，不留 diff。

所以有一個我一開始完全沒預料到的結果：

AI 沒有讓責任變模糊。它讓一件本來就模糊的事，第一次被迫寫下來。

取代的是動作，不是責任

那天委員會上還有一個沒被問出口、但每個人都在想的問題：這個東西上了，品管室是不是可以少幾個人。

這個問題在製造業有一個更直接的版本——問的是現場的班長還要不要。答案兩邊通用：

AI 取代的是流程節點上的動作，不是責任。所以你的組織圖不會少一格——但每一格裡的人，可以管更多事。

「讀完三百份病歷」是一個動作，可以被取代；「為這三百份的結論負責」不是動作，是一格組織圖。

你的 CI 也是這樣長大的：它接走了跑測試這個動作，沒有接走「這個 release 能不能出」這個決定。可以被接走的都是動作——讀完、比對、抽候選、產初稿、把非結構化文字整成欄位。而有三項，我到現在沒找到任何交出去的方法：

一、定義什麼叫「好」。 模型可以幫你把定義寫得更清楚，但「我們這家醫院認為這樣算不合格」是一個價值選擇，它需要一個會被追究的人。

二、承擔後果。 判錯了要去單位說明、要在委員會上解釋、要面對申復——這一格只能是人，因為承擔的前提是會痛。

三、跨部門協調與例外判斷。 這條判準對 7B 病房不適用，因為他們的流程跟別人不一樣——這件事永遠不會出現在任何一份輸入裡（Day 3 的第三層），它只會出現在一場你必須親自去開的會裡。

這三項合起來，剛好就是 Day 1 那句話：訂判準、做判斷、負說明責任。 中間那一格被動了，另外兩格一動也沒動。

所以組織圖不會少一格。變的是每一格能管多少事——過去一位資深同仁一個月能為二十份病歷負責，現在他能為全院的判準負責。那不是同一份工作變輕，是換了一份更難的工作。

AI 側：三個跟責任有關的設計

一、輸出的形狀，決定人的行為

最早那版輸出的 schema 很直覺：對每一份病歷給「合格／不合格」再附一段理由，複核者只要點同意或不同意。

後來換掉了。換掉的理由不是準確率，是人的行為。

一個已經寫成結論的輸出，人的角色是「推翻」。而推翻一個看起來很有把握的結論，心理成本非常高：你要說得出理由、要說服自己、還要擔心是不是自己看漏了。人在這個位置上，預設動作就是按同意。

把輸出換成「疑似項目 ＋ 依據落在病歷原文哪一段 ＋ 把握程度」之後，人的角色從推翻變成認定——而認定這個動作，你非得自己去看那一段不可。

差別不在介面，在責任的方向：一個是你要有理由才動，另一個是你要有理由才不動。

你把輸出寫成結論，人就只會按同意。你把輸出寫成證據，人才會真的去看。

有人提過折衷：輸出結論、但把把握程度藏起來以免錨定。那更糟——複核者連分配注意力的依據都沒了。該藏的不是把握程度，是結論。

二、失效模式：理由跟判定不同源

這是我在這條流程上最擔心的一層。

模型寫得出理由，問題是那段理由不一定是判定真正的來源：把同一筆資料的判定人為翻轉過來再要它寫理由，它兩邊都寫得出讀起來很有道理的理由。在別的場景這是小問題——反正結論對就好；在責任脈絡下它是致命的：

申復程序處理的是理由，不是結論。

這跟一份 postmortem 一樣：沒有人會因為「結論是對的」就收下一份講不出因果的 postmortem。單位不服的時候，桌上攤開來吵的是「你憑什麼說這裡不合格」；如果那段理由是事後生成的，它經不起第二個問題——而申復桌上一定會有第二個問題。

更值得注意的是這個失效有方向：它的理由穩定地往「文件上找得到的字句」偏。 它擅長引述，不擅長指出缺漏——可是稽核發現的缺失大多數恰恰是「缺」：缺一次評估、缺一個確認、缺一個該有的時間點。有字的東西它抓得住，沒字的地方它得推論，而推論正是理由最站不住的部分。

所以流程上加了一條硬規則：輸出必須帶原文位置。指得出位置的理由才算理由；指不出位置的，降級成提示，不成案。

這犧牲了一部分真的存在、但指不出位置的缺失。取捨是有意識的：寧可漏掉幾個吵不贏的，也不要在申復桌上被打掉一次——第一次被打掉，整套系統的信用就沒了。 一句話：稽核判定要進得了申復桌，理由就得指得到病歷上的字。

三、自動化機制：覆蓋紀錄變成回饋迴路

每一次人推翻系統，留下原判、改判，以及 Day 25 那個必選的理由分類（判準本身有問題／AI 讀錯了原文／這是情境例外）。

一開始這只是為了留痕。累積一段時間之後，它變成整條流程裡最有價值的東西——一份判準的缺口清單，分成兩堆：一堆是 AI 穩定判錯的類型，修得動；另一堆是人跟人本來也不一致的那一類（Day 20 那個問題），那不是 AI 的錯，是判準沒寫清楚，AI 只是把它照出來了。

而覆蓋率本身就是一個指標，兩端都是壞消息：太高，代表系統的產出不能用；太低，代表沒有人真的在看。你們有精確的對應物：alert 的 ack 率、PR 從開啟到 approve 的時間中位數——approve 得太快不是效率高，是沒看。

反過來看更嚴重：一個完全沒有人反駁紀錄的系統，不是很準，是沒有人在看。

而且覆蓋率的變化是漂移的早期訊號：Day 26 的管制圖要等一個週期，覆蓋紀錄每天都在產生。人比統計量先聞到味道。

這三件事加起來，才讓這條流程從「一次性的判定」變成一條會自己長大的東西：

系統的輸出被人改掉的那一刻，才是資料真正產生的時候。

那天之後

那場委員會之後，我們花掉的時間有很大一部分不在調模型，在畫那張表：誰簽名、誰申復、哪些欄位不要產生。那些工作不會出現在任何一份技術文件裡，但它們決定了這個東西上線之後活幾個月。

技術上，它在那天早就可以上線。能不能活過第一年，取決於第一線覺得它是拿來幫忙看的，還是拿來看著他們的。而這件事沒有任何一行程式解決得了——是你把哪些欄位放進 schema、把簽名欄放在哪一格、申復的按鈕擺不擺在同一個畫面上。

制度是寫在資料結構裡的，不是寫在會議紀錄裡的。